The cmake step relied on $ENV{PROGRAMFILES} in FindCuvis.cmake to
find the SDK at C:\Program Files\Cuvis\bin. On the current Windows
runner image this expansion may not resolve correctly. Passing
CMAKE_PREFIX_PATH explicitly makes cmake search the SDK bin
directory directly, bypassing the env-var lookup.

- Add C:\Program Files\Cuvis\bin to PATH in cmake step so the
  version-check binary compiled by try_run can load cuvis.dll
- Use python -m pip instead of pip to avoid WinError 5 access
  denied on pip.exe self-upgrade (Python 3.9 on Windows)

…talled files

Caching C:\Program Files\Cuvis and restoring it in a downstream job
does not replicate the registry entries and PATH changes the installer
makes, so cmake's try_run version check could not load cuvis.dll.

Instead: setup-windows-deps now only caches the installer zip at a
workspace-relative path (reliable to restore). Each build-and-test-
windows matrix job restores the zip and runs the full NSIS installer,
which sets up the complete system state needed by FindCuvis.cmake.

Keep CMAKE_PREFIX_PATH and PATH additions in the cmake step so the
current session sees the SDK regardless of when the installer's PATH
change propagates.

Python 3.9 reached EOL in Oct 2024 and is not installable via
actions/setup-python@v5 on Windows Server 2025 runners. Linux jobs
continue to cover 3.9 via deadsnakes PPA in Docker containers.

The bash version ran via Git Bash which swallowed the version output.
Now uses pwsh consistently with the rest of the Windows job steps.